The following is from Azure Administrator Training lab for AZ-103

Resource Manager

The infrastructure for your application is typically made up of manycomponents – maybe a virtual machine, storage account, and virtual network,or a web app, database, database server, and third-party services. You maynot see these components as separate entities, instead you see them as relatedand interdependent parts of a single entity. You want to deploy, manage, andmonitor them as a group.

Azure Resource Manager enables you to work with the resources in yoursolution as a group. You can deploy, update, or delete all the resources foryour solution in a single, coordinated operation. You use a template fordeployment and that template can work for different environments such astesting, staging, and production. Resource Manager provides security,auditing, and tagging features to help you manage your resources afterdeployment.

Consistent management layer

Resource Manager provides a consistent management layer to perform tasksthrough Azure PowerShell, Azure CLI, Azure portal, REST API, and clientSDKs. All capabilities that are available in the Azure portal are alsoavailable through Azure PowerShell, Azure CLI, the Azure REST APIs, andclient SDKs. Functionality initially released through APIs will be representedin the portal within 180 days of initial release.

Choose the tools and APIs that work best for you – they have the samecapability and provide consistent results.

The following image shows how all the tools interact with the same AzureResource Manager API. The API passes requests to the Resource Managerservice, which authenticates and authorizes the requests. Resource Managerthen routes the requests to the appropriate resource providers.

Benefits

Resource Manager provides several benefits:

• You can deploy, manage, and monitor all the resources for your solutionas a group, rather than handling these resources individually.
• You can repeatedly deploy your solution throughout the developmentlifecycle and have confidence your resources are deployed in aconsistent state.
• You can manage your infrastructure through declarative templatesrather than scripts.
• You can define the dependencies between resources so they’re deployedin the correct order.
• You can apply access control to all services in your resource groupbecause Role-Based Access Control (RBAC) is natively integrated intothe management platform.
• You can apply tags to resources to logically organize all the resources inyour subscription.
• You can clarify your organization’s billing by viewing costs for a groupof resources sharing the same tag.

Guidance

The following suggestions help you take full advantage of Resource Managerwhen working with your solutions.

• Define and deploy your infrastructure through the declarative syntax inResource Manager templates, rather than through imperativecommands.
• Define all deployment and configuration steps in the template. Youshould have no manual steps for setting up your solution.
• Run imperative commands to manage your resources, such as to start orstop an app or machine.
• Arrange resources with the same lifecycle in a resource group. Use tagsfor all other organizing of resources.

Terminology

If you’re new to Azure Resource Manager (ARM), there are some terms youmight not be familiar with.

• resource – A manageable item that is available through Azure. Some common resources are a virtual machine, storage account, web app, database, and virtual network, but there are many more.
• resource group – A container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group. You decide how you want to allocate resources to resource groups based on what makes the most sense for your organization.
• resource provider – A service that supplies the resources you can deploy and manage through Resource Manager. Each resource provider offers operations for working with the resources that are deployed. Some common resource providers are Microsoft.Compute, which supplies the virtual machine resource, Microsoft.Storage, which supplies the storage account resource, and Microsoft.Web, which supplies resources related to web apps.
• ARM template – A JavaScript Object Notation (JSON) file that defines one or more resources to deploy to a resource group. It also defines the dependencies between the deployed resources. The template can be used to deploy the resources consistently and repeatedly.
• declarative syntax – Syntax that lets you state “Here is what I intend to create” without having to write the sequence of programming commands to create it. The Resource Manager template is an example of declarative syntax. In the file, you define the properties for the infrastructure to deploy to Azure.

Resource providers

Each resource provider offers a set of resources and operations for working with an Azure service. For example, if you want to store keys and secrets, you work with the Microsoft.KeyVault resource provider. This resource provider offers a resource type called vaults for creating the key vault.

The name of a resource type is in the format: {resource-provider}/{resource-type}. For example, the key vault type is Microsoft.KeyVault/vaults.

✔️ Before getting started with deploying your resources, you should gain an understanding of the available resource providers. Knowing the names of resource providers and resources helps you define resources you want to deploy to Azure. Also, you need to know the valid locations and API versions for each resource type.

Resource Group Deployments

Resources can be deployed to any new or existing resource group.Deployment of resources to a resource group becomes a job where you cantrack the template execution. If deployment fails, the output of the job can describe why the deployment failed. Whether the deployment is a single resource to a group or a template to a group, you can use the information to fix any errors and redeploy. Deployments are incremental; if a resource group contains two web apps and you decide to deploy a third, the existing web apps will not be removed. Currently, immutable deployments are not supported in a resource group. To implement an immutable deployment, you must create a new resource group.

Resource Groups

Resource Groups are at their simplest a logical collection of resources. There are a couple of small rules for resource groups.

• Resources can only exist in one resource group.
• Resource Groups cannot be renamed.
• Resource Groups can have resources of many different types (services).
• Resource Groups can have resources from many different regions.

Guidance for creating resource groups

There are some important factors to consider when defining your resource group:

• All the resources in your group should share the same lifecycle. You deploy, update, and delete them together. If one resource, such as a database server, needs to exist on a different deployment cycle it should be in another resource group.
• Each resource can only exist in one resource group.
• You can add or remove a resource to a resource group at any time.
• You can move a resource from one resource group to another group.
• A resource group can contain resources that reside in different regions.
• A resource group can be used to scope access control for administrative actions.
• A resource can interact with resources in other resource groups. This interaction is common when the two resources are related but don’t share the same lifecycle (for example, web apps connecting to a database).

When creating a resource group, you need to provide a location for that resource group. You may be wondering, “Why does a resource group need a location? And, if the resources can have different locations than the resource group, why does the resource group location matter at all?” The resource group stores metadata about the resources. Therefore, when you specify a location for the resource group, you’re specifying where that metadata is stored. For compliance reasons, you may need to ensure that your data is stored in a particular region.

✔️ By scoping permissions to a resource group, you can add/remove and modify resources easily without having to recreate assignments and scopes.

Resource Manager Locks

A common concern with resources provisioned in Azure is the ease with which they can be deleted. An over-zealous or careless administrator can accidentally erase months of work with a few clicks. Resource manager locks allow organizations to put a structure in place that prevents the accidental deletion of resources in Azure. You can associate the lock with a subscription, resource group, or resource. Locks are inherited by child resources.

Locks come in two varieties.

• Read-Only locks, which prevent any changes to the resource.
• Delete locks, which prevent deletion.

✔️ Only Owner and User Access Administrator roles can create or delete management locks.

Moving Resources

Sometimes you may need to move resources to either a new subscription or a new resource group in the same subscription.

When moving resources, both the source group and the target group arelocked during the operation. Write and delete operations are blocked on theresource groups until the move completes. This lock means you can’t add, update, or delete resources in the resource groups, but it doesn’t mean the resources are frozen. For example, if you move a virtual machine to a new resource group, an application accessing the virtual machine experiences no downtime.

Before beginning this process:

• Review services that can be moved.
• Review services that cannot be moved.

To move resources, select the resource group containing those resources, andthen select the Move button. Select the resources to move and the destinationresource group. Acknowledge that you need to update scripts.

✔️ Just because a service can be moved doesn’t mean there aren’t restrictions. For example, you can move a virtual network, but you must also move its dependent resources, like gateways.

Removing Resources and Resource Groups

Resource Groups

Use caution when deleting a resource group. Deleting a resource groupdeletes all the resources contained within it. That resource group mightcontain resources that resources in other resource groups depend on.

Using PowerShell to delete resource groups

To remove a resource group use, Remove-AzResourceGroup. In this example,we are removing the ContosoRG01 resource group from the subscription. Thecmdlet prompts you for confirmation and returns no output.

Resources

You can also delete individual resources within a resource group. Forexample, here we are deleting a virtual network. Notice you can change theresource group on this page.

Using PowerShell to delete a resource

To remove an individual resource use, Remove-AzResource. You will need theResourceId. In this example, we are removing a website. You could also usethe resource name.

ARM Templates

Template Advantages

Using Resource Manager templates will make your deployments faster and more repeatable. For example, you no longer have to create a VM in the portal, wait for it to finish, then create the next VM, and so on. Resource Manager takes care of the entire deployment for you.

Here are some other template benefits to consider:

• Templates improve consistency. Resource Manager templates provide a common language for you and others to describe your deployments. Regardless of the tool or SDK that you use to deploy the template, the structure, format, and expressions inside the template remain the same.
• Templates help express complex deployments. Templates enable you to deploy multiple resources in the correct order. For example, you wouldn’t want to deploy a virtual machine prior to creating an operating system (OS) disk or network interface. Resource Manager maps out each resource and its dependent resources, and creates dependent resources first. Dependency mapping helps ensure that the deployment is carried out in the correct order.
• Templates reduce manual, error-prone tasks. Manually creating and connecting resources can be time consuming, and it’s easy to make mistakes. Resource Manager ensures that the deployment happens the same way every time.
• Templates are code. Templates express your requirements through code. Think of a template as a type of Infrastructure as Code that can be shared, tested, and versioned similar to any other piece of software. Also, because templates are code, you can create a “paper trail” that you can follow. The template code documents the deployment. Most users maintain their templates under some kind of revision control, such as GIT. When you change the template, its revision history also documents how the template (and your deployment) has evolved over time.
• Templates promote reuse. Your template can contain parameters that are filled in when the template runs. A parameter can define a username or password, a domain name, and so on. Template parameters enable you to create multiple versions of your infrastructure, such as staging and production, while still utilizing the exact same template.
• Templates are linkable. You can link Resource Manager templates together to make the templates themselves modular. You can write small templates that each define a piece of a solution, and then combine them to create a complete system.
• Templates simplify orchestration. You only need to deploy the template to deploy all of your resources. Normally this would take multiple operations.

Template Schema

An Azure Resource Manager template precisely defines all the ResourceManager resources in a deployment. You can deploy a Resource Managertemplate into a resource group as a single operation.

Azure Resource Manager templates are written in JSON, which allows you toexpress data stored as an object (such as a virtual machine) in text. A JSONdocument is essentially a collection of key-value pairs. Each key is a string,whose value can be:

• A string
• A number
• A Boolean expression
• A list of values
• An object (which is a collection of other key-value pairs)

A Resource Manager template can contain sections that are expressed usingJSON notation, but are not related to the JSON language itself:

For more information, you can see:

Understand the structure and syntax of Azure Resource Manager Templates –https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-authoring-templates#template-limits

Template Parameters

Parameters

This section is where you specify which values are configurable when thetemplate runs. For example, you might allow users of your template to specifya username, password, or domain name.

Here’s an example that illustrates two parameters: one for a virtual machine’s (VM’s) username, and one for its password:

"parameters": { "adminUsername": { "type": "string", "metadata": { "description": "Username for the Virtual Machine." } }, "adminPassword": { "type": "securestring", "metadata": { "description": "Password for the Virtual Machine." } } }

Template Variables

Variables

This section is where you define values that are used throughout the template.Variables can help make your templates easier to maintain. For example, youmight define a storage account name one time as a variable, and then use thatvariable throughout the template. If the storage account name changes, youneed to only update the variable once.

Here’s an example that illustrates a few variables that describe networkingfeatures for a VM:

"variables": { "nicName": "myVMNic", "addressPrefix": "10.0.0.0/16", "subnetName": "Subnet", "subnetPrefix": "10.0.0.0/24", "publicIPAddressName": "myPublicIP", "virtualNetworkName": "MyVNET" }